[データアナリティクス事業本部] チーム異動して1年弱経ったので働き方などを振り返ってみた

データアナリティクス事業本部(以降、DA事業本部)ビジネスソリューション部のnagamasaです。

本記事では、私自身がポテンシャル採用から今の部署/チームに異動した経験などを踏まえて働き方がどう変わったかを振り返ってまとめています。

部署/チームについて

簡単に私が所属している部署/チームについて、紹介いたします。

現在はビジネスソリューション部ビッグデータチームに属しています。(入社時はアプリ保守チームに所属)

ビッグデータチームは、いわゆるビッグデータを扱うデータ分析基盤の設計・構築を担当する開発メインのチームになります。

詳細については、下記のブログで紹介されているので、あわせてご覧ください。

チーム異動について

ざっくりと異動の変遷を書くと、下記のような流れで今に至ります。

• 2020/05〜 : クラスメソッドにジョイン
  • 当時はDA事業本部直下のアプリ保守チームに配属
• 2021/07〜 : 組織改編に伴い、ビジネスソリューション部アプリ保守チームに配属
• 2021/10〜 : 育休取得(1ヶ月)
• 2021/11〜 : ビジネスソリューション部ビッグデータチームに異動

プロフィール

簡単なプロフィール紹介になります。

• クラスメソッド勤続年数は2年半弱 (2020/05ジョイン)
• 妻、子(1歳半)と沖縄住まい
  • 結婚、出産のタイミングで沖縄にUターン転職
• 那覇オフィス所属
• 前職では、主に国内クラウドサービスの基盤開発に従事
  • スキルセットとしては、Java、SQLあたりがメイン

現在に至るまで

入社

私の場合は、「Pythonエンジニア」として応募したのですが、応募時はスキル不足であったため、運用・保守メインのアプリ保守チームでの条件付き採用という形で入社できました。

まずはアプリ保守チームでAWSやデータ分析基盤に関わる経験を積んでいただきたいとの言葉をいただき、いわゆる「ポテンシャル採用」でのジョインとなりました。

アプリ保守チーム

1案件のみアサインして、主な業務としては下記がメインでした。

• データ分析基盤上のエラー対応(調査・リカバリ)
• お客様からの要望対応
  • データ再取込対応
  • データマートのロジック改修(JavaやSQLの改修)
  • (データソース追加に伴う)新規バッチの追加対応
• メインで扱うAWSサービスとしては、Amazon Redshift(以降、Redshift)がメイン

入社当初は、AWSの経験がほぼなかったのですが、上記の案件を通しRedshiftの操作などからキャッチアップすることができました。

そもそもデータ分析基盤に関わる業務も初めてであったので、基本的な用語であるETL(Extract/Transform/Load)とは？みたいなところから案件を通して学ぶことができました。

やはり運用保守なのでエラーなども緊急性が高いタスクが多く、スピード重視なタスクをこなしていくという面でもいい業務経験ができました。

育休取得

プライベートなイベントとして、2021/04に第一子の出産がありました。

2021/09の中旬ごろまで子供が入院していたので、2021/10/01 〜 2021/10/31 の丸1ヶ月間で育休を取得させてもらいました。

※会社やチームの皆さんに入院の事情もご理解いただいた上での調整をすることができ、1ヶ月間子供とたくさん触れ合う時間ができました。

育休に入る1カ月前くらいから引き継ぎを始め、まずは自分が担当している定常業務や各タスクに必要な事前情報などを(Backlog上の)Wikiに整理したりしました。

エラー対応などについては、ビデオ会議(Google Meet)上で口頭でのコミュニケーションを取りながら、ペアで対応したりしました。

ビッグデータチーム

2020/11/01〜ビッグデータチームに配属となり、今までと違って開発寄りな案件にもアサインさせてもらいました。

案件としては、2つアサインさせてもらい、主な業務内容としては下記になります。

• 案件A
  • AWS上のデータ分析基盤構築案件
  • メイン業務は追加開発やパフォーマンス改善
  • 既存のリファクタリングや不具合修正
  • 1スプリントを2週間とするスクラム開発
  • メインで扱うAWSサービスとしては、Amazon Athena(以降、Athena)がメイン
• 案件B
  • AWS上のデータ分析基盤の運用保守設計支援案件
  • メイン業務は運用保守見直しや他ベンダーへの運用保守の移管業務
    • 移管に伴うドキュメント作成
    • QA対応
    • 簡単な運用スクリプト実装
  • WBS管理や工数見積もりなどのマネジメント寄りな業務

案件Aでは、業務を通してAthenaをキャッチアップすることができ、Pythonや複雑なSQLの改修など入社前に希望していた開発寄りな業務を経験させてもらっています。

案件Bでは、開発というよりかは運用保守に近いのですが、今まで経験のなかったマネジメント寄りな業務もできて、いい経験ができていると感じております。

部門受け入れ

案件外の社内業務として、新規ジョインメンバーやビジネスパートナー(BP)様の受け入れ業務もメインで担当しています。

毎月初めの営業日は、半日ほど受け入れ対応に時間を確保して、下記などを対応しています。

• 受け入れMTG
  • 簡単な自己紹介
  • 部門体制やメンバーの紹介
  • 勤怠や稼働報告などの説明
  • 各勉強会や部内活動などの紹介
• 各種セットアップや申請などのフォロー

案件外でも部のために貢献できるやりがいがあり、また新規ジョインメンバーから「手厚いフォローありがとうございました！」などの言葉をもらえると小さな達成感があります。

とある1日のスケジュール

現時点のとある1日のスケジュールになります。

• 09:30 〜 業務開始
• 10:30 〜 朝会(案件A)
• 11:00 〜 開発作業(案件A)
• 12:00 〜 お昼休み
• 13:00 〜 定例会議(案件B)
• 15:00 〜 中抜け1(子供の送迎)
• 16:00 〜 QA対応、WBS更新(案件B)
• 17:30 〜 中抜け2(子供のお風呂など)
• 18:00 〜 開発作業(案件A)
• 20:00 〜 退勤

アプリ保守チーム所属時と業務や働き方が大きく変わったなと思う大きなポイントは、下記2つです。

複数案件アサイン

アプリ保守チーム時代は、丸1日1案件に集中して作業ができたのですが、 現在は2つの案件にアサインしているので、丸1日一つの案件作業をするといった日は基本的に少ないです。

ビッグデータチーム配属直後は、案件ごとに工数バランスをうまくとることに一苦労した記憶があります。

中抜け

子供の送迎などで、よく中抜けを使っています。

案件やチームとの調整は必要に応じてやっていますが、特に休暇申請のような申請は不要で中抜けを利用できるのはとてもありがたいです。

アプリ保守チーム時代は、契約条件上の運用・保守の時間(09:30 〜 18:00)が決まっていて、今のような柔軟な中抜けはあまりできなかったので、1日の働き方が大きく変わりました。

地方オフィスで働き方

私は沖縄在住なので、那覇オフィス所属しています。

私が入社した頃は、3〜4人しか那覇オフィスメンバーがいなかったのですが、現在(2022/10)はアノテーションのメンバーを含めて約15人に増えています。

那覇オフィス所属なのですが、直近までは原則リモートワーク推奨であったため、入社当初から在宅での業務がメインでした。

直近は全国的にオフィス出社されている方も増えており、那覇オフィスのメンバーも出社頻度が増えてきました。

今後は自分自身も出社頻度を増やして、積極的にオフィスのメンバーとも対面のコミュニケーションをとっていきたいと思います。

また沖縄という場所もあり、那覇オフィス以外のメンバーもワーケーションがてらに那覇オフィスに来たりしてくれています！

また休日は、沖縄ならではの海沿いのゴルフコースに行って、趣味のゴルフを堪能したりしています。

おわりに

私自身の経験を踏まえて、「ポテンシャル採用からのチーム異動」という観点で記事を書いてみました。

DA事業本部の他メンバーの働き方ブログや、部署毎のお仕事紹介ブログなども公開されているのであわせてご覧ください！

上記のブログなどのおかげもあり、今月(2022/10)も3名のメンバーがジョインしてくれました！

新規メンバーのジョインブログを見て私自身もこれまでを振り返ろうと思ったのがきっかけでした。

これから似たような境遇で応募を迷われてる方などの一助になれば幸いです！

募集要項

ビジネスソリューション部の募集要項になります。

気になった方は、カジュアル面談も適宜開催しておりますので、お気軽にエントリーください。

エンジニア募集要項

PM(プロジェクトマネージャー)/PL(プロジェクトリーダー)募集要項